aprs: adding working supply #453
Conversation
| const results = (await multicall.execute()) as { | ||
| [address: string]: { | ||
| inflationRate: BigNumber | undefined, | ||
| workingSupply: BigNumber |
There was a problem hiding this comment.
v1 gauges don't have a workingSupply
There was a problem hiding this comment.
true, it will be used only in V2 and mainnet.
| * @param gaugeAddresses | ||
| * @returns | ||
| */ | ||
| private async getMainnetGaugeRates(gaugeAddresses: string[]): Promise<{ [gaugeAddress: string]: GaugeRate }> { |
There was a problem hiding this comment.
are there also v1 and v2 mainnet gauges that need separate handling?
There was a problem hiding this comment.
no, it's too much branching. i refactored it, but it's still quite hard to read.
| const abi = [ | ||
| 'function working_supply() view returns (uint256)', | ||
| 'function gauge_relative_weight(address) view returns (uint256)' | ||
| ]; | ||
| const multicall = new Multicaller3(abi); |
There was a problem hiding this comment.
the gaugeController ABI is present under modules/vebal/abi . I'd suggest to move to modules/web3/abi and import from there. If we do this inline like this, I'm sure at some point the gaugeController changes and these functions are different
There was a problem hiding this comment.
changed to the ABI, we might need to do some work anyways when it changes.
There was a problem hiding this comment.
this import seems to be breaking in the github workflow, would you know why?
|
|
||
| const weightedRates = _.mapValues(gaugeData, ({ weight }) => { | ||
| if (weight.eq(0)) return 0; | ||
| return inflationRate * Number(formatUnits(weight)); |
There was a problem hiding this comment.
I usually to parseFloat(), is there a difference?
There was a problem hiding this comment.
no difference, changed to parseFloat
| }); | ||
|
|
||
| const gaugeData = await multicall.execute() as { [address: string]: { weight: BigNumber, workingSupply: BigNumber } }; | ||
| const inflationRate = emissions.weekly(now) / 604800; // BAL inflation rate per second |
There was a problem hiding this comment.
Couldn't we just use
/**
* @notice Returns the current inflation rate of BAL per second
*/
function getInflationRate() external view returns (uint256) {
return _rate;
}
from the tokenAdmin contract?
There was a problem hiding this comment.
yes we could. should I add it this call? it's returning exactly the same data.
There was a problem hiding this comment.
that would be great if you could add it. I like to have an onchain query rather than local calculation, saves a lot of code and less room for error
| @@ -470,6 +470,7 @@ model PrismaPoolStakingGauge { | |||
| rewards PrismaPoolStakingGaugeReward[] | |||
| status PrismaPoolStakingGaugeStatus @default(ACTIVE) | |||
| version Int @default(1) | |||
| workingSupply String @default("0.0") | |||
There was a problem hiding this comment.
this needs to be added to pool.prisma in the pool module
| @@ -1,221 +1,252 @@ | |||
| /** | |||
| * Supports calculation of BAL rewards sent to gauges. Balancer setup has 3 types of gauges: | |||
There was a problem hiding this comment.
also supports any thirdparty reward tokens
| @@ -92,12 +92,22 @@ export class GaugeAprService implements PoolAprService { | |||
| const aprItemId = `${pool.id}-${rewardTokenDefinition.symbol}-apr`; | |||
| const aprRangeId = `${pool.id}-bal-apr-range`; | |||
|
|
|||
| // Only 40% of LP token staked accrue emissions, totalSupply = workingSupply * 2.5 | |||
| const workingSupply = (parseFloat(preferredStaking.gauge.workingSupply) + 0.4) / 0.4; | |||
There was a problem hiding this comment.
you already get the working supply, why +0.4)/0.4 ?
include working supply in Mainnet and V2 gauges APR calc
…nd into aprs-fixes
Adding working supply to the BAL APR calculations. There are still differences on mainnet after checking with the current SDK APRs.